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ABSTRACT 



This ihesis provides a description of a collection of "tools" which may be used 
by acquisition program managers. The Modular Command and Control Evaluation 
Structure (MCES) provides the framework for management of the process. The 
.Marine Corps Technical Interface Concepts (TIC) and interoperability database (IDB) 
are discussed as standards for filling four of the seven MCES modules. Finally, generic 
measures of communications system performance are described and used in 
conjunction with System Effectiveness Analysis (SE.A) to define the analytical process 
of measuring effectiveness. 
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I. INTRODUCTION 



A. BACKGROUND 

Acquisition of major weapons systems has become a progressively more 
complicated process. This is due, in part, to the complexity of modern warfare. 
Integrated (interoperable) contmand and control (C^) systems are required to 
effectively harness and employ the destructive nature of military' forces. Integration 
demands measures to overcome technical intricacies and elTorts to master the political 
and cultural pressures highlighted in the following quote [Ref 1; p. ii]. 



GETTING INTERSERVICE AGREEMENT IS THE MOST DIFFICULT 
PH.ASE; Service dilferences in doctrines., operations, logistics, and procedures 
tend to diversifv svstem designs. When joint acquisitions are ordered by the 
Secretary of Defense or the Consress, the biaaest hurdle is getting the services to 
aaree oh joint requirements. Each service oelieves that its concept of a new 
afrcraft. missile, or vehicle will be best for the mission and will oppose 
compromise of its design or performance aoals. Agreement is still more elusive 
when one or another svstem is alreadv well into development with a "hardened" 
desien. decisions firmed, costs sunk, ahd a dedicated constituency in place. This 
is when many program mergers are ordered. 



The Department of Defense has outlined procedures directed at resolving integration 
(interoperability) issues. At the heart of this enterprise is a requirement to outline a 
joint Command, Control and Communications (C^) architecture and to build a joint 
interoperability database [Ref 2; p. 4-5|. The multifarious nature of this endeavor 
makes it necessary to collect tools to describe, in structured terms, the process of 
command and the communications necessary' to control diverse elements. 

B. SCOPE 

This thesis will focus on four tools that can be used by acquisition managers to 
consolidate and refine the measures and specifications necessary' to affect a systematic 
approach to procurement. Specifically, these devices can assist supervisors in refining 
mission needs and stipulating the requirements necessary' to meet these demands. The 
Modular Command and Control Evaluation Structure (MCES) will provide the 
framework for evaluating C architectures. Generic system attributes need to be 
defined and assigned numeric values, where possible and practical, to be analyzed. 
This thesis will define, in the author's words, essential communications considerations 
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used by Marine Corps communications managers. Marine Corps Technical Interface 
Concepts (TIC) are applied to describe the boundaries and process definitions, 
integrate these descriptions, and then provide data for specified measures. Finally, 
System Effectiveness Analysis (SEA) outlines a quantitative approach to aggregate and 
evaluate recommended measures. 

C. THESIS OUTLINE 

This thesis is organized into eight chapters. Chapter II describes the framework 
of MCES, in acquisition related terms. Chapter III defines communications attributes. 
While not an all-encompassing list, it provides generic considerations to be used to 
specify Measures of Performance or Effectiveness. Chapter IV outlines the Marine 
Corps Technical Interface Concepts followed by an explanation of System 
Efiectiveness Analysis (Chapter V). Chapter VI then applies the previously described 
tools to a C'^ system. Chapter VII summarizes the results and recommends areas for 
further research. Appendix A provides a dictionary of acronyms and terms used to 
describe this process. The sources for these definitions include JCS Publication 1, 
"DoD Dictionary of Military and Associated Terms," January 1986, and the references 
cited throughout the text. This thesis assumes a basic knowledge of communications 
engineering principles and of the acquisition process. Appendix B provides an 
overview of the acquisitions process. Inasmuch as regulations are constantly changing. 
Appendix B is somewhat dated; however, the principles and structure remain essentially 
unchanged. 
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II. MODULAR COMMAND AND CONTROL EVALUATION 
STRUCTURE (MCES) METHODOLOGY 



A. INTRODUCTION 

The Modular Command and Control Evaluation Structure (MCES) is a 
framework for systems planners and evaluators to assess C“ architectures. By 
extension, it is a useful basis for analyzing the communications processes necessary to 
support command and facilitate control. Its functional applications may extend 
beyond the bounds of C'^ studies. This thesis will concentrate on defining its utility as 
an acquisitions guide to evaluate, inter alia, communications interoperability. 

B. BACKGROUND 

The development of MCES was initially triggered by a challenge to Air Force 
planners to determine the force effectiveness of C^ systems. This implied a search for a 
means of analyzing these systems throughout their life-cycle. Expert knowledge of the 
analytic community was focused through a conference chaired by Dr. Ricki Sweet and 
LtCol Thomas Fagan III, US.AF. Five working groups were formed to address: 
Definitions, Conceptual .Models, the Identification of Measures of Effectiveness 
(MOEs), Evaluation Techniques and .Approaches and an overall appraisal of the 
current status and future course of MOE analysis. 

Based on an expressed interest and need for further attention to C^ systems' 
contribution to force effectiveness, an effectiveness "strawman" was developed by Drs. 
.Mort .Metersky, Michael G. Sovereign, and Ricki Sweet to provide a framework for 
subsequent deliberations at the MORS (Military Operations Research Society) 
sponsored workshop. An integrated document describing MCES was published in June 
1986 [Ref 3: pp. 19-21]. MCES has been tested and refined through service 
community input [Ref 4] and through the voluntary contribution of government, 
military and civilian agencies, and companies [Ref 3: p. 24]. 

This chapter provides an explanation of MCES presented, where appropriate, 
with reference to DoD acquisition requirements. It is a restatement, in the author's 
words, of the methodology described by Dr. Sweet [Ref 3: pp. 9-18]. 
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Figure 2.1 The Modular Command and Control Evaluation Structure. 

C. METHODOLOGY 

The MCES (Figure 2.1) consists of two components: (1) managerial and (2) 
analytical systems. The former guides the user through specification while the latter 
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outlines analysis processes (both objective and subjective). The MCES is intended to 
guide problem specification and analysis in order to provide a manager with concise 
conclusions thereby enhancing decision making. This direction is accomplished 
through use of seven modules using pragmatic, established techniques. 

1. Module 1: Problem Formulation 

Module I describes the decision maker's objectives. These objectives should 
fill a mission need and demonstrate a level of performance and reliability that justify 
the allocation of the Nation's limited resources for the system's ownership and or 
acquisition [Ref 5: p. 4]. Implementation of this module results in a more precise 
statement of the problem to be addressed. Problem formulation should consider 
elements of not only mission assignment but also the intelligence or threat assessment 
and scenario(s) underlying the analysis. 

2. Module 2: C" System Bounding 

The problem statement developed in Module 1 is then used to bound the 
system of interest. This module has been perhaps one of the most overlooked elements 
in preparation of acquisition strategies and Justification for Major System New Starts 
(JMSNS). Bounding the project allows managers and engineers to focus their efforts 
rather than attempt description of a panacea for all existing deficiencies. Module 2 
specifies the first two of the three dimensions which define a system, namely; 

• physical entities (equipment, software, people and facilities); 

• structure (organization, concepts of operation and information flow patterns); 
and, 

• process (the functionality or "what the system is doing"). 

Bounding in this module occurs when the project team defines who or what entities 
have a requirement to interact (process - the final dimension developed further in 
the next module) in what manner or along what lines (structure). 

3. Module 3: C“ Process Definition 

Understanding the system bounds allows a focused description of Command 
and Control processes (Module 3). Other generic models such as Boyd's O-O-D-A and 
Lawson's control loop are applied to force attention on: 

• the environmental "initiator" of the C^ process; 

• the internal processes that characterize what the svstem is doing (ex. sense, 
assess, generate, select, plan, and direct) (see Figure 2T.2); and/or, 

• the inputs and desired outputs from the internal process. 
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Figure 2.2 Generic Command and Control Process. 

4. Module 4: Integration of System Elements and Functions 

The fourth module verbally or graphically depicts the three dimensional 
system. It maps entities with their required processes, forming the structure necessary’ 
to answer the mission objective of Module I. Techniques such as Data Flow Diagrams 
(DFDs) are frequently used to show the information (low through the model. 
Hierarchical relationships are drawn as data progresses through the system to a 
decision maker or into master databases for further or future processing. 

5. Module 5: Specification of Measures (Criteria) 

The definitive processes of the preceding modules lead logically to the 
specification of measures necessary to address the problem of interest. These measures 
are classified as to their level of measurement. 
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a. Measures of Performunce (MOPs) 

Measures of Performance are specified inside the boundary' of the 
system [Ref 4: p. 17], that is, they measure performance of the system processes. A set 
of generic Communications MOPs will be presented in Chapter III. An example of a 
communications performance measure would be a specific bit error rate (BER) 
requirement for a data transmission system. 

b. Measures of Effectiveness {MOEs) 

Measures of Effectiveness (MOEs) are specified outside the boundary of 
the communications system [Ref 4; p. 17]. MOEs are C^ process measures placed on 
the system being evaluated in the context of the system's effect on the larger (Force) 
process. They describe a force action or lack thereof impacted or directed by the 
system. As an example, in order to ENGAGE an enemy (Force level) you first have to 
FIN'D or LOCATE (system level) him. 

c. Measures of Force Effectiveness {MO EEs) 

.Measures of Force Effectiveness (MOFEs), then, describe the force effect 
on its environment. These combine all of the system's performance and effectiveness 
measures and could describe such things as battle outcome or target destruction. 
Figure 2.3 portrays the aforementioned relationships. 

The specified measures are subjected to further scrutiny by comparing them 
to a set of criteria (Table 1) reducing the number to a more manageable set. The final 
list is taken to be critical or the minimum necessaiy to measure the problem at hand. 

6. Module 6; Data Generation 

Module 6 addresses the requirement to generate data relative to the Measures 
specified in Module 5. Data can be generated through any number of means (i.e., 
exercises, experiments, simulations, or subjective judgement). In the acquisition 
process, values are generated for specified measures relative to the force and 
environment (MOE MOFEs) and then to system entities (MOPs). This would imply a 
top-down design approach. It also implies an iterative process wherein specification 
dependencies are highlighted, analyzed and resolved. Chapters IV and V will describe a 
means of acquiring data to describe the generic communications MOPs outlined in 
Chapter III. 

7. Module 7: Aggregation of Measures 

The final module addresses aggregation or analysis of the previously defined 
system. As support for a J.MSNS, analysis may determine the essential features of a 
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new system's elTect on the force compared with programs already in existence (DoD 
Milestone 0). Following a decision to acquire (DoD Milestone 1). investigation is 
conducted into alternative means in order to refine requests for proposals (RFPs) and 
generate a specific statement of work (SOW). Finally, the system measures are 
compared with proposals and products through the full scale development phase and 
used to determine contractor qualification for contract. 

Existing systems are evaluated as changes to mission statements and objectives 
are directed to demonstrate or validate their utility in the force as a whole. 

D. DECISION MAKER 

The products provided by the MCES modules are presented to a decision maker. 
Three general courses of action are then available. The results may be implemented 
based on the analysis. Alternatively, a need for further study, refining any or all of the 
Modules, may be directed. Finally, a decisionmaker may terminate the process. 
VICES does not define a specific decision process. This is left to the manager to 
describe. The process may be entirely subjective based on the evaluator's personal 
assessment of the data generated. It may be ver>’ objective, based solely on numbers 
generated combined with weighted measures. Or it could encompass any combination 
of these processes. As a generic tool, VICES specifies only the logical framework or 
process of the evaluation. It remains a function of leadership to define the decision 
process. 
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MOP - Measure of Performance 
MOE • Measure of Effectiveness 
MOPE - Measure of Force Effectiveness 
MOPE - Measure of Policy Effectiveness 
MEO - Message Exchange Occurence 
(See Chapter IV) 

NCA - National Command Authority 



Fieure 2.3 



Measures Specification - The "Onion Skin". 



I 



19 





TABLE 1 




CRITERIA 


CHARACTERISTICS 


DEFINITIONS 


Mission Oriented 


Relates to force/system mission 


Discriminatory 


Identifies real difference between 
alternatives 


Measurable 


Can be computed or estimated 


Quantitative 


Can be assigned numbers or ranked 


Realistic 


Relates realistically to the C2 system 
and associated uncertainties 


Objective 


Can be defined or derived, independent 
of subjective opinion. (It is recognized 
that some measures cannot be 
objectively defined). 


Appropriate 


Relates to acceptable standards and 
analysis objectives 


Sensitive 


Reflects changes in system variables 


Inclusive 


Reflects those standards required 
by the analysis objectives 


Independent 


Is mutually exclusive with respect 
to other measures 


Simple 


Is easily understood by the user 
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III. MEASURES 



A. INTRODUCTION 

The MCES, described in Chapter II, directed specification of measures as the 
requirement for Module 5 of the Structure. This chapter will describe the efforts of 
JTC'^.A in their research on specifying measures [Ref 6] and then outline generic 
communication system measures, recommended by this author, to be considered as a 
guide in acquisition planning. The Technical Report referenced in the introduction and 
its accompanying appendi.x [Ref 7] present the preliminary JTC^A results on 
assessment and evaluation techniques for joint tactical command, control and 
conununications systems, networks, links and facilities. The JTC'^A work has 
attempted definition of MOE's for five major C" elements (see Table 2). In keeping 
with the thesis scope, the controlling factors outlined will refer to the communications 
element of the C'^ architecture. 

B, BACKGROUND 

Analysts define and use MOEs in the development of system and sub-system 
architectures. Commencing with work conducted by the Joint Tactical 
Communications Office (TRI-TAC) in the 1970-S0 time period in which seventeen 
measures were published, to date about two hundred VlOEs have been identified and 
defined by JTC'^.A [Ref 6: p. 4j. Some of these are hardware oriented and therefore 
technical in scope such as "ECCM.LPI". ".Antenna Gain", and "Transmission Power." 
Others are non-technical requirements relating to such functions as "Monitoring", 
"Capability to Select Options, Employ Forces, and Execute Operations" and 
"Responsiveness to Warning and Threat .Assessments." Certain measures address total 
system orientation such as ".Vlaintainability", "Survivability", and "Mobility." JTC^A 
emphasizes that "...these VIOEs are structured for preliminary design comparison." In 
the -MCES framework, they are also useful when applied and evaluated in an iterative 
fashion as tools to define the system or sub-system bounds. In other words 
specification of the measures themselves may help refine initial bounding when 
performance or efiectiveness standards (MOPs .MOEs) fail to meet or answer problem 
objectives. This occurs as the decision maker is presented with architectural 
alternatives which address a stated mission need (determined in Module 1). 
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C. MOE ORGANIZATION AND FORMAT 

The JTC'^A listing of MOEs is organized into five groups as shown in Table 2 
These correspond to the five major elements mentioned in OJCS SM-7-S2 
[Ref. 6: p. 5]. They are divided further into sub-elements, also illustrated in Table 2. 
Communications is visualized as the bonding agent of systems and is categorized in 
terms of "transmission" and "connectivity distribution." Keeping with the scope of this 
work, this author will describe the Communications category and specific generic 
measures to be considered when describing or defining a system. This is contrary to 
the global JTC^A approach wherein measures are specified by communications media 
type. 

Reference 7 uses the format presented in Table 3 to present specific measures. 
Inasmuch as this represents a goal which JTC'^A has yet to realize, the title and 
definition of each measure will be used in this thesis. Coniments regarding evaluation 
will be presented in a discussion section. Sources and data requirements will be 
omitted for the generic measures. The "MOP or MOD Title" line refers to the 
Vleasures of Performance (MOP) previously discussed and Measures of Design (MOD) 
representing field operational characteristics (ex., "Transportability" and 
"Maintainability"). The reference admits no great significance in the distinction 
[Ref 6: p. 6]. In order to prevent confusion and follow the MCES outline, only 
"MOPs" will be listed in the title lines for this work. 

D. GENERIC MEASURES 

1. Introduction 

This section presents generic measures of performance to be applied to 
communications systems analysis in the VICES framework. The measures listed are in 
no particular order of importance. While perhaps lacking in depth of description and 
breadth of attribute (measure) coverage, it should provide the reader a skeleton on 
which to build a more comprehensive listing. It is understood that many of these 
measures are interrelated. Parameters or characteristics of one may impact or alTect 
another. Some of these relations are highlighted. Others may have been omitted. It 
remains a requirement for the analysis team using these measures to describe 
interdependencies as complementaiy or disparate and develop the decision tools to 
compromise or obviate differences. JTC^A also emphasized that their measures are 
proposed for communications systems only. This also applies herein. The measures 



JAUU: 2 

ORGANIZATION Of JOINT TACTICAL C3 MOL CA ILGORILS 



1. Command Facilities 

A. Main Command Centers 

B. Alternate Command Centers 

2. Communications 

A. Tactical HF Systems 

B. Line of Sight Systems 

C. Tropo 

D. Switching 

E. Wire/cable/fiber optics 

F. Satellite 

G. Combined System Networks 

3. Warning (Surveillance) 

A. Ground 

B. Surface 

C. Sub'Surface 

D. Space Based 

E. Tethered Balloons 

4. Command and Control Procedures 

A. Procedures 

B. Reports 

C. Frame Formats 

D. Modularity Techniques 

5. Command and Control Data Collection and Processing 

A. Netted Systems 

B. Centralized Data Bases 

C. Point-to-point Systems 



discussed stem from system anrihutes defined for Marine communications managers. 
It is felt that aiiribuies of an efikient eflective communications system should relate to 
measures used in evaluating proposed and existing systems. 
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TABLE 3 

FORMAT FOR EACH MOE 

MOP or MOD TITLE; 

DEFINITION: or description of what the title measures 

METHODOLOGY: either qualitative or quantitative for preparing 
the measure, Including Important parameters, factors, 
models and considerations 

SOURCES: that are useful for further research 

DATA REQUIREMENTS: for using the algorithms and models 



2. Reliability 

a. Definition 

Measures (tlie) probability that an item will perform its intended function 
for a specified interval under stated conditions [Ref 7; p. A- 14]. 

b. Discussion 

Reliability is usually expressed in terms of Mean Time Between Failure 
(MTBF). Coupled with maintainability, it impacts availability of the communications 
system. MTBF is usually measured in hours. Military standards exist to describe 
component specifications and, by extension, can be used to describe system 
requirements. 

Reliability may imply redundance which measures duplication of 
components. A high reliability requirement coupled w'ith low M'fBF will normally 
require redundancy which will usually impact system life cycle cost (both initial 
procurement and supportability). 

Component reliability measures may depend on element placement in the 
system. Higher priority elements will normally require higher restoral ability, 
impacting the value assigned to reliability. 

Link reliability expresses an assurance that communications will function 
accurately [Ref 8: p. 2-4]. In this sense transmission elTiciency, receiver sensitivity, and 
receiver selectivity are considered quantitative measures. 
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c. Conclusion 



The following elements can be used in defining a reliability measure: 

• Overall Reliability Requirement (Measured in percentages) 

• Component MTBF (in hours) 

• Redundancy (No. of backup components required) 

• Receive Sensitivity (ability to detect signals) 

• Receive Selectivity (ability to dilTerentiate signals) 

• Transmission Efficiency (includes SNR Error Detection Techniques) 

• Required Bit-Error-Rate (BER) 

• Mean Time to Repair (MTTR) 

3. Interoperability 

a. Definition 

The condition achieved among communications electronics systems or 
items of communications electronics equipment when information or services can be 
exchanged directly and satisfactorily between them and or their users. The degree of 
interoperability should be defined when referring to specific cases. 

The ability of systems, units, or forces to provide services to and accept 
services from other systems, units or forces and to use the services so exchanged to 
enable them to operate elTectively together. (JCS Pub 1) 

b. Discussion 

Communications interoperability, while seemingly simple to define, has 
been characteristically difficult to attain. Interoperability is a function of: 

Equipment compatibility; 

Interface operating procedures; and. 

Message formatting and design standards. 

Interoperability may be measured with respect to any or all of these functions. 

Technical Interface Standards consist of specifications of the functional, electrical, and 

physical characteristics necessary to allow the exchange of information across an 

■> 

interface between different tactical systems or equipment [Ref 2: p. 2-1]. 

Procedural standards consist of specifications for the manner of accomplishing the 

exchange of information across an interface. They define: 

The form or format in which information is to be exchanged; 

the prescribed, information exchange language, syntax, and vocabularv to be 
used in the information exchange; and. 
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interface operating procedures that govern the information exchange [Ref 2: p. 

(1) Compatibility. Elements or parameters to be considered when ensuring 
communications compatibility include modulation, frequency range, range, signalling, 
cryptographic hardware and software, and interface connectivity. Of the 
aforementioned parameters, interface connectivity is, at times, the most dilTicult 
element of compatibility element to achieve. Intra and interservice Command and 
Control Elements (C“E's) use a wide variety of computer and radio control 
equipments. In designing a system, existing terminal devices must be considered for 
numerous reasons, not the least of which is cost. DoD has a stated policy to minintize 
the number of bulTering, translative, or similar devices to achieve interoperability 
[Ref 9: p. 2|. A judicious use of modems, buffers and translaters must routinely be 
designed into conmiunications architectures to ensure interoperability. 

(2) Message Formatting and Design. Message formating and design 
features are specified in the JCS, JIXTACCS (Joint Interoperability of Tactical 
Command and Control Systems) program as well as in Technical Interface Design 
Plans (TIDPs) (Addressed in Chapter IV). Elements are combined, in an approved 
sequence, to form a standard message. Once it is determined that input messages to a 
transmitting device match output messages in a receiver, compatibility is said to exist. 
Where discontinuities exist, measures are taken to resolve differences. For example, if 
operationally required formats do not exist in the JINTACCS system, then justification 
is drawn to include the message as a new standard. Once this justification is accepted, 
new message formats are derived. A process wherein this is accomplished is described 
in Chapter IV, Technical Interface Concepts. 

(3) Interface Operating Procedures. Interface operating procedures, while 
ultimately linked to the format and design features already addressed, are developed as 
a result of Combined and Joint Service training and exercises. These require agreement 
on the part of all agencies as to, ultimately, the method(s) by which elements, 
commands, and forces are directed or controlled in a tactical environment. There are 
several stumbling blocks to acquisition planners as well as operational commanders. 
First, achieving a unified view is particularly difficult given unit and service 
parochialism. Next, qualifying or quantifying this requirement requires extensive 
operational tests and/or simulation. Finally, tradeoffs that are made during the 
acquisition process may impact reliability, speed, flexibility, economic factors, or even 
the entire project success. 
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c. Conclusion 

The following elements can be used in quantifying an interoperability 

measure: 

• Overall Communications Interoperabilitv Requirement (Measured in 

Percentages) 

• Modulation - The extent to which both equipments are capable of 
operating using the same modulation scheme 

• Frequencv Ranae - The extent to which equipments have the same (or 
nearlv the samCl frequencv ranee and tunine capabilitv to accommodate 
assigned frequencies (applicable for RF systenTs) 

• Range - distance or coverage of the system affected bv transmit power, 
antenna gain, receive sensiti\aty. repeaters, propagation and terrain 

• Sienalline - The nature of such tvpes as analog or dieital, in-band or out- 
oi^and;etc.. 

• Crx'ptographic - The extent to which hardware is compatible with the radio 
or'wire~svstem. Software must be approved for, be compatible with, and be 
available'to all desired users. 

• Interface Connectivitv - The extent to which the communications svstem 

supports each element specified in the problem definition (Module 1 - 

MCtS) and bounded (in .Module 2 - .MCK). 

• Message Format and Design - The extent to which required messages meet 
existing criteria or that additional standards must be created. 

• Interface Operating Procedures - again, in answering the Module I 

requirements and .Module 2 bounds, tlfe extent to which all elements are in 

agreement as to direction and control. 

4. Speed 

a. Definition 

Speed denotes timeliness in the flow of information between users of 
communications [Ref S: p. 2-5]. Speed is a communication element measure of 
performance supporting the timeliness measure of effectiveness of the system. 

b. Discussion 

A quantitative measure of speed is based on operational urgency. Speed is 
usually defined for digital systems in terms of bits-per-second (BPS) or baud rate. It is 
dependent on the communications means chosen and the efficiency of technology and 
design. Speed is also controlled by procedures. Personnel training and adherence to 
precedence as well as other message designators may impact conununications speed. 
In addition to BPS and Baud rate, speed may be determined by: throughput, switching 
rate, routing plan, human message handling speeds, dialing method, precedence levels, 
processor speed and capacity; and, queueing [Ref. 7: p. A-26]. 
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Grade-of-Service (GOS) for switched (circuit, message, and packet) systems, 
indicating a probability of a call (message) being blocked or delayed more than a 
specified interval, could also be used as a measure of speed. GOS varies from 
subjective ratings such as excellent, good, fair, poor or unsatisfactory, to quantitative 
probability calculations based on the following generalized equation [Ref 7: p. A-24]. 

GOS = f(T.C,R..A.D) where: 

1 = traffic volume bv type of service (in erlanas) 

C = channel capacity 
R = alternate routing capabilitv 

A = call or message arrival prolDability distribution (assumed to 
be poisson dfstributed for commercial communications) 

D = channel degradation 

c. Conclusion 

The following elements may be used in supporting speed as a measure of 
performance; 

• Overall Required Speed (measured in time) 

• BPS or Baud Rate Required 

• Throughput 

• Switching Rate 

• Routing plan 

• Human message handling speeds 

• Dialing method (touch-tone, rotary' or operator assist) 

• Precedence levels 

• Processor speed and capacity 

• Queuing 

• GOS required 
5. Security 

a. Definition 

Security is the protection resulting from all measures designed to deny 
unauthorized persons information of value which might be derived from the possession 
and study of communications, or to mislead unauthorized persons in their 
interpretation of such a study [Ref 8; p.2-4], 

b. Discussion 

The four elements of communications security (COMSEC) are: crypto 
security, transmission security, emission security and physical security. 

Crypto security results from the provision of technically sound 
cryptosystems and their proper use [Ref 8: p.6-19j. In acquisition of communications 
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systems this involves working closely with the National Security Agency (NSA), the 
certifying authority for new systems applications. Cr\pto security measures may 
impact interoperability. As an example, a crypto system in use on one type of HF 
radio may not be approved for use with a new design. While all of the other 
compatibility measures may match, a requirement for a new crypto system seriously 
impairs interoperability, perhaps rendering the new design unsuitable. The requirement 
for cr\'pto security may also degrade flexibility. Cryptographic material, both hardware 
and software, is issued with the realization that only loss of the software will 
compromise the system and then only for the period the software is in elfect. 
Consideration must be given to the area in which the equipment will be employed. Use 
in a hazardous region may require limited distribution or minimal holding of the 
material impacting system flexibility. Alternatively, a system applying a remote keying 
scheme may be more costly and require more training to operate, affecting simplicity 
and economy. 

Transmission security results from all measures designed to protect 
transmissions from interception and exploitation by means other than crypto analysis 
[Ref 8: p. 6-22], conunonly referred to as LPE, LPI (Low Probability 

Exploitation Intercept). Limited exploitation relates to the ciyptographic capability to 
mask the information content of the transmission. This is often measured by the 
amount of time necessary to decipher the text without a key. The limited probability 
of intercept measures the range within which an enemy must be in order to detect and 
intercept a signal. This implies knowledge of the enemies capabilities and intentions 
and or predicted future abilities which should have been considered in the Problem 
Formulation and System Bounding stages of the MCES. In determining the 
probability of intercept or effect on a communications system, planners will use such 
parameters as; range (from enemy jammer; receiver), transmit power (jammer and or 
friendly transmitter), type of signalling and modulation, receiver allowed bit-error-rate 
(HER), antenna design, and propagation factors (including terrain). 

Emission security refers to that component of COMSEC resulting from 
measures taken to deny information of value that may be derived from intercept and 
analysis of emanations from crypto equipment and telecommunications systems 
[Ref 8: p. 6-26]. Care must be taken in systems design to reduce unintended 
emanations from tactical equipments. Such signals may appear as electromagnetic 
radiation from constant key sources, conducted emanations, powerline modulation, or 



29 



acoustic emanations. All are susceptible to interception and exploitation either to 
disclose classified information, to allow direction finding of transmitter sites, or to 
permit identification of electronic order of battle fingerprints of headquarters elements. 
.Adherence, by both designer and operator, to TEMPEST requirements, established by 
XSA, should effectively reduce the unintended emanations. Simulation and operational 
testing of a proposed system coincident with existing systems should aid designers and 
operators in identifying and overcoming architectural weaknesses relative to emission 
security. 

Physical security refers to the component of COMSEC resulting from all 
physical measures taken to safeguard classified equipment, material, and documents 
from access to or observation by unauthorized persons [Ref. 8: p.6-27]. Physical 
security, like cr\'pto security, impacts the design process relative to flexibility and 
economy. The requirement to safeguard systems and software may impact universal 
usage and, or drive acquisition costs past on acceptable level. 

c. Conclusion 

The following parameters may be used in describing security as a measure 
of performance: 

• Overall Security Requirement 

• Economic (Cost) constraint 

• Crypto (hardware; software compatibility) requirement 

• Required probability of intercept/exploitation 

• Known or projected enemy capabilities 

• TEMPEST requirement) s) 

6. Flexibility 

a. Definition 

.Adaptable to change (Random House Dictionary). The ability to support 
a wide dispersion of units under adverse or varying conditions [Ref. 8; p. 2-5). 

b. Discussion 

The Marine Corps definition is limited in that it implies a universal use and 
is directed more towards the planning and integration of all systems to support 
command and control. It requires acquisition sponsors to consider the combined 
effects of proposed and existing systems and to study the results of operational tests 
before committing to full-scale production. 
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Because of the versatile nature of modern warfare, flexibility also infers 
mobility, or the ability to retain command and control while on the move. This 
influences size, weight and transportability of equipment, personnel and logistics to 
support the system. 

The dictionary definition indicates an ability to change by expanding, 
contracting or reorganizing the service provided. It may also allow change of modes 
within a specified range of operation. For instance; an error control may be relaxed for 
digitized voice and increased for data transmission. Or. in order to improve emission 
security, transmission power may be tunable to the least amount necessary to ensure 
reception limiting the range of interception. 

c. Conclusion 

Flexibility determinants include: 

• .Ability to expand, contract, or reorganize service 

• Choices of bit rate 

• Choice of transmitter power 

• Choice of error control 

• .Mobility factors 
7. Sunivability 

a. Dejinition 

.All measures taken to prevent disruption of communications by 1) enemy 
interference or natural disaster [Ref 8: p. 2-7] and, 2) measures the capability to 
survive conventional, nuclear and CBR attack for continuity of operation under the 
worst probable conditions of conllict [Ref 7: p. A-S]. 

b. Discussion 

As a function of the sum of the aforementioned factors, the survivability 
measure must be evaluated as constrained by budgetary considerations. 

Disruption by enemy interference has been covered, albeit obliquely, under 
transmission security. The same parameters, ie., range, transmit power, type of 
signalling and modulation, BER, antenna design, and propagation factors, are used to 
determine the effect of communication januners. The use of similar design parameters 
do not adversely alTect measure independence. The equations used to derive the 
measures are unique. 

Measures to prevent natural and or man-made disaster include such 
elements as redundancy (outlined under Reliability) and design. Design criteria 
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describe the physical characteristics of equipment necessary to withstand chemical, 
nuclear and conventional damaging elTects. Such requirements inherently drive- up 
costs as physical properties are reinforced and electronic components are built or 
backed-up to withstand the affects of electromagnetic pulse (EMP). 

Survivability is also enhanced by the .VIobility factors listed under 

Flexibility. 

c. Conclusion 

Survivability determinants include: 

• Overall Survivability Requirement 

• Economic (cost) constraint 

• Redundancy (Number of backups required) 

• Range 

• Transmit power 

• Signalling and modulation 

• BER 

• Antenna design 

• Propagation factors (including terrain and weather) 

• Mobility factors 
8. Simplicity 

a. Definition 

The ease of access and operation for users, and the ease of installation, 
operation and maintenance for operators [Ref 8: p. 2-7]. 

b. Discussion 

Simplicity, easy to define, is becoming characteristically ignored in new 
systems development. The technology that allows a reduction in operations manning, 
at times, increases the demand on communications managers and personnel. Thus, 
from both budgetary (in terms of manpower) and simplicity perspectives, trade-olTs 
must be made in order to find the optimum mix between operations and 
communications. 

Simplicity may also affect flexibility. A flexible system, one with many 
options, may be complex to operate and maintain, yet meet the definition demands of 
Module 1 (MCES). 

c. Conclusion 

Simplicity considerations include; 

• Simplicity requirement; balanced against. 



• Budgetan’ (Manpower training) impact 

• Flexibility and mission need statements 
9. Economy 

a. Definition 

Economy results from actions taken to ensure the best use of available 
communications personnel, equipment and supplies etc.( Random House Dictionary). 

b. Discussion 

While previously mentioned as a constraining parameter for other 
measures, economy, or a degree of economy, should be considered as a measure itself 
Given a cost constraint, the acquisition manager must balance the bounded mission 
need against the cost of acquiring the measures necessary to support the requirement. 
Hence, the budget is compared with the sum of the costs of supporting each measure. 
Simply put. if cost exceeds budget, the manager must justify a request for increased 
funds, reiterate the MCES process, or reconunend project cancellation or re-definition. 

c. Conclusion 

Economy requires conciliation between the project and existing demands 
for scarce resources (money, personnel and equipment). Given a budgetary or cost 
restriction, the decision maker must make ever}' eflort to stay within these guidelines 
while ensuring, first and foremost, that the mission requirement (.Module 1) is resolved. 

E. MEASURE INTERACTION 

The introduction to the previous section alluded to potential interrelationships 
between measures. Figure 3.1 graphically portrays these associations. The 
dependencies or connections are represented by the lines drawn between the measures. 
.Arrows indicate flow. While it may certainly be debated that all measures are related, 
one to another, the links shown depict the author's subjective judgement of the most 
important effects. Other analytical means, beyond the scope of this thesis, are needed 
to determine degrees of interaction. Sensitivity analysis or a database of past 
experience are two possible ways to define measure interplay. 

F. CONSIDERATIONS 

Numeric values approaching 100% are desired for some of these measures 
(reliability, interoperability, security, flexibility and survivability). While verbal merits 
such as "fastest" (speed), "least expensive" (economy), and "uncomplicated" (simplicity) 
would describe others. However, use of such terms is not only impractical but 
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Figure 3.1 .Measures Interactions. 

unattainable. When specifying these measures, consideration must be given to their 
underlying parameters and overall system requirements. For example, while it may be 
nice to have a system that will operate at 5 mcgabits-per-second, to cover every 
eventuality, if the computer processing speed at the terminal's input and output is 1000 
bits-per-sccond. too much slack has been required in the variable. Relative to the 
previous discussion, this may adversly affect cost with no necessitated gains. In short, 
the quantitative or qualitative descriptions required must represent reality. 

.Another consideration involves a standard, or nearly standard means of attaining 
values for measures. The Marine Corps' fechnical Interface Concepts (Chapter V) 
represents an attempt at regulating this process. By describing the statics involved, the 
process between elements, and comparing these with existing integrated systems, the 
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process becomes regulated. Anomalies require justification For addition to existing 
databases. Similarities aid in starting the process of detailed requirements listings. If. 
for example, a similar task (process) is required of other elements (statics) within the 
database, decomposition may well lead to physical properties already used to support 
such a function. These values lend a starting point for requirements. More important, 
the point is already employed by the organization, in this case The Marine Corps, and 
adherence to such a level, while perhaps not imperative in this specific application, may 
well serve to assist future endeavors. Suppose the message standard leads to a 
bandwidth specification of 5 Mhz impacting speed, reliability, security, and economy 
(for this example). While not a critical or required measure in this case, the designated 
parameter affects (positively) interoperability thereby allowing for possible expansion 
of the desired system into other applications. 

Relative importance of measures at the acquisition management level is 
dependent ultimately, and optimally, on support of the mission need described in 
Module 1. This is determined, in the final analysis, on performance under actual 
operating conditions. However, decisions involving performance and effectiveness must 
be made much earlier in the process. Lacking 'fool-proof means of weighting 
measures, the decision maker must make, at times subjective, judgements as to 
associated merit. This may again require an iterative process. Political reality 
currently mandates interoperability, reliability, and economy as critical measures. A 
'generic' ranking is certainly unwise and description of decision theor\‘ is beyond the 
scope of this thesis. One means, or consideration, is certainly worth mentioning. 
While seemingly self-evident, the decision maker must assure amelioration of both 
operator and systems engineers in the process. Failure to consider the input of one or 
the other may lead to disastrous consequences. 

Two final points need to be stressed. While the measures (MOPs in this case) 
may be interrelated, the equations used in defining them are not. The parameter 
'range' may be used in determining both 'speed' and 'security'. However, the 
formulation of these must be kept separate. .Mathematically, while security may be a 
function of range (security = f( range....)) and speed is a function of range (speed = 
range....)), the functions are unique even if the design parameters are equal. 

Finally, both quantitative and qualitative standards have merit in the analysis. 
While numeric values may be desirable, they are not always attainable. Verbal 
descriptors may point to debate and subjective judgement; however, a measures' merit 



is not to be based on an ability to assign an arithmetic rate. The measure is necessary 
because it aids in characterizing the system. Omitting qualitative measures would 
result in an incomplete description. 

G. SUMMARY 

This chapter has defined and described generic measures of performance to be 
used in analysis of a conununications system. As part of the description, a listing of 
parameters was derived to support derivation of each measure. Table 4 reflects the 
results. While perhaps not all inclusive, it represents a point of departure for system 
analysis. 



36 





tabu: 4 

GLNERIC MEASU RES 


Measure 


Paramelers 


Reliability 


Component MTBF, Redundancy, Receive 
Sensitivity, RecelveSelectIvity, Transmission 
Efficiency, Required BER, Mean Time to 
Repair 


Interoperability 


Modulation, Frequency Range, Range, 

Signalling, Cryptographic, Interface Connectivity, 
Message Format and Design, interface 
Operating Procedures 


Speed 


BPS or Baud Rate Required, Throughput, 
Switching Rate, Routing Plan, Human 
message handling speeds, Dialing method. 
Precedence levels, Processorspeed and 
capacity. Queuing, GOS Required 


Security 


Economic (cost) constraint. Crypto 
(hardware/software compatibility) 
requirement, Required probability of 
Intercepl'exploltatlon, Known or projected 
enemy capabilities, TEMPEST requirement(s) 


Flexibility 


Ability to expand, contract, or reorganize 
service. Choices of bit rate. Choice of 
transmitter power. Choice of error control. 
Mobility factors 


Survivability 


Economic (cost) constraint. Redundancy, 
Range, Transmit power. Signalling and 
modulation, BER, Antenna design. 
Propagation factors. Mobility factors 


Simplicity 


Budgetary (manpower/training) impact. 
Flexibility and mission need statement 


Economy 


Conciliation between the project and existing 
demands for scarce resources. 
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IV. TECHNICAL INTERFACE CONCEPTS 



A. INTRODUCTION 



Powerful, sophisticated, command and control (C2) systems that exploit a rapidlv 
expanding technological base are becoming realities;' yet, issues concerning thefr 
integratioTi into the larger context of a conimand and control architecture remain 
unresolved. Militarx' planners require clearlv defined standards of compatibilitv 
and interoperabilitv'to retrofit fielded systems, modify those currentlv in design, 
and plan for future ones. A major goal of the Department of Defense is''to 
provide these planners with accurate, detailed information about their particular 
svstem requirements, about the interrelationship of their tactical svstem with 
o'ther svstems, and about the impact that svstem will have on the architecture as 
a whole. 



Achievement of this goal requires development of a suitable method for 
identifving. capturing, organizing, and accessing information necessarv^ to 
describe current and projected svstems. Succinctlv stated, the militarv must 
develop a usable model of its C2 architecture. This model must provide two 
essential premises. First, it must answer detailed questions about the C2 
structure, providing a view of that structure in its totalitv as well as its 
particulars. Second, it must provide input to programs engaged in dvnamic 
analvsis such as wargame scenarios and network loadmg studies [Ref 10]. 



This quote provides a concise statement of DoD and Marine Corps' objectives 
relative to managing contmand and control architectures. Most of the references cited 
in this chapter have to do specifically with inter and intraoperability, yet in 
standardizing interoperability and acquisition management processes and 
responsibilities, it also provides a systematic mechanism for compliance with the 
bounding, process definition, integration, and data generation modules of the MCES. 
This chapter w'ill describe the Technical Interface Concepts (TIC) and Marine Corps 
Interoperability Management Plan (IMP) principles applicable in the MCES 
framework pertinent to communications acquisition and management. 

B. PURPOSE 

The overall objective of the Interoperability Management Plan (IMP) is to 
ensure the exchange of critical tactical information. This is accomplished at two levels; 
first, on a Marine Corps unique level (referred to as intraoperability) then, on a joint or 
combined level between Marine Air Ground Task Forces (MAGTFs) and other U.S. or 
Allied conunands. The IMP centralizes and standardizes procedures for management 
activities. These procedures aim to accomplish the following: 
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• Identify the manner in which existing and new interoperability requirements and 
standards are identified, defined, standardized, and documented. 

• Facilitate the implementation, yerification. testing, and certification of those 
standards in developing tactical data systems (TDSs) and interconnecting 
equipment. 

• Prescribe coordination between the various configuration management bodies 
and activities that control modifications to requireTnents, standards, TDSs, and 
interconnecting equipment. 

• Ensure that interoperability program requirements are adequately planned for 

and funded [Ref if; p. l-3f. ‘ 

The Technical Interface Concepts (TIC) document identifies and establishes 
Marine Corps command, control, and communications (C^) facility and systems 
operational interface requirements for both current and future periods. It is a baseline 
from which other USMC interoperability technical documents, standards, and 
specifications are developed [Ref 12: p. 1-1]. The objective of the TIC is to provide 
the framework to ensure that fielded Marine Corps Tactical Command and Control 
Systems (MTACCS) are compatible, interoperable, and operationally effective. In 
keeping with the IMP, MT.ACC systems are first intraoperable, then interoperable with 
other than Marine systems. Compatibility with other service systems is to be attained 
through application of the JINT.ACCS (Joint Interoperability of Tactical Command 
and Control Systems) program. 

C. PHILOSOPHY 

The MT.A.CCS concept of standardizing automated interfaces has been to ; (1) 
standardize at the "transmission format" level, (2) leave the man-machine interface to 
be resolved by individual system requirements and constraints, and (3) to bit-code 
messages and data items. The JINTACCS concept has evolved to one of 
standardizing: (1) both at the machine and human levels, (2) for voice, record, and 
automated interfaces, and (3) character codes for data items. In order to maintain 
compatibility in JINTACCS Allied operations. MTACCS systems engineering has 
maintained compatibility at the data item level and dev'eloped message conversion 
protocols for specific interfaces [Ref 12; p. 1-2]. 

D. METHODOLOGY 

This section will address the specific set of procedures designed to determine 
specifications and standards from validated operational (or mission) requirements. The 
mission requirements formulation is the responsibility of Mission Area Sponsors. 
These sponsors conduct .Mission Area Analyses (MAAs) in an elTort to validate 
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current requirements and to define future operational needs. A command and control 
architecture is then developed to facilitate the aggregation of associated elements 
required to support mission needs. The basic entities of a C'^ architecture are 
illustrated in Figure 4.1 (author's concept) and described below [Ref 11: p. 3-3]. 




Figure 4.1 Marine Corps C‘~ Architecture. 

1. Operational Facilities 

Otherwise referred to as C“Es (Command and Control Elements) in the 
parlance of Joint planners, Operational Facilities (OPFACs) are those elements tasked 
with perfornting the C“ Process functions described in Chapter II (Table 4). Each C^E 
consists of equipment, communications, facilities, personnel, and procedures required 
to assist the commander in carr>ing out his C^ responsibilities. They vary widely in 
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size and complexity from a single forward observer (FO) to a large, integrated Fire 
Support Coordination Center (FSCC). 

2. Tasks 

OPFAC or C"'E tasks are those functions performed by the C^E requiring it 
to exchange information with other C^Es. They are extracted from existing documents 
reflecting approved doctrine, procedures and techniques contributing to the overall 
conmiand and control function. 

3. Message Elements/Standards 

Elements are the fundamental details of information used to construct 
messages. Message elements are composed of standard Data Field Identifiers (DFls), 
Data Use Identifiers (DLTs) and Data Items (DIs). These standards are used to 
implement information exchange in Marine Corps TDSs. The elements are collected 
and formed into standard messages and documented in the Technical Interface Design 
Plan (TIDP). 

4. Equipment and Link Requirements 

C“Es relate to one another as cither source or sink (sender or receiver) of the 
messages described above. This relation implies a requirement to establish a 
communications link in support of information flow. The link is established using 
TDS's interconnected with communications equipment, each of which can be 
characterized by their functions. Communications links are defined in terms of 
operational characteristics and constrained by technical factors. Ultimately, the link 
requirements are specified in terms necessary' to support mission needs. Compliance 
with these needs allows specific description of the link and its associated equipment. 

5. Protocol Standards 

Protocols are the rules or procedures by which information is transferred 
through systems, interconnecting equipments, and networks. Marine Tactical System 
(MTS) protocols are defined by an eight-layered reference model beginning with the 
transmission media and ending with user application. The model and standards are 
documented in the TIDP. 

6. Message Exchange Occurrences 

A command and control architecture is typically represented as a Data- Flow- 
Diagram (DFD). The circles representing nodes and the connecting lines 
communications links. A specific node in a network may be comprised of one or 

more C^Es. For example, an Infantry Battalion node may be made up of Fire Support 
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Coordination Center (FSCC) and Combat (Jperation«; Center (COC) In keeping 

with the previous discussion of architectural elements, the lines must also represent 
messages to be transmitted along the link. Without the message requirement the link is 
idle. The most basic network, then, consists ol two OLs, a link, and a message that 
transports information along the link. 'Ihis relation is portrayed in Figure 4.2. 
Limiting the description further, to the transmission of a single message, requires a 
discrete information transfer. This is termed a .Message Exchange Occurrence (MFO). 
Validated MEOs establish a requirement for interoperability and at the same time a 
system requirement in support of the basic mission need. 




E. IMPLEMENTATION 

A listing of all validated MEOs is useful in portraying an architecture as it exists 
in its "potential" state. In order to model the C^ process in a specific "kinetic" state. 
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orOer must he subscribed to tlie MEOs describing flow of C“ activity as a sequence of 
events [Ref. 10|. Ihc modelling process is illustrated in I'igure 4.3. '1 he model can be 
used to define specilic measures of elfectiveness and then validate the system support 
of mission need. Even a superficial understanding of military structure would suggest 
to the reader that a listing of MEOs is quite extensive. 1 his section will explain how 
MEOs are derived, used to build a network, and used to model command and control. 
This description follows closely the work of Pipho (Ref 10|. 




A GENERIC EXAMPLE 




A SPECIFIC EXAMPLE 



figure 4.3 MEO Chain. 

1. Information Base 

Ihc number of MEOs is seemingly limitless. Many pages would have to be 
written to clEectively capture the information content of all .MEOs. Screening the 
potential exchange capabilities and requirements to find matches or similarities for 
potential architectures would be a grueling task. An automated database would 
expedite this process improving management of both existing and potential O’ systems. 

1 he .Marine Corps Interoperability Database (IDB) is being designed to 
provide improved management, integrity, and communication ol' inter intraoperability 
information. I he IDB will provide the automated tools to: 
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• standardize and centralize inter intraoperability data; 

• manage proposed changes to interoperability requirements and standards; 

• automate and manage the documentation process (TIC.TIDP); 

• automate compliance tracking; and. 

• coordinate between interoperability requirements and standards. 

Additionally, a fully functional IDB will provide a basis for the implementation of 
future applications such as: 

• simulation of inter, intraoperability scenarios under battlefield conditions; and. 

• determine alternative communication interfaces/configurations [Ref 13: p. 3]. 

The first step in developing the IDB is to identify and describe the basic 
components that define the architecture. Then the relationships that exist between 
these components are specified and entered into the base of information. 

At the most general level, the architecture components are: 

• C-Es (OPFACs) 

• C^E tasks 

• C^E resources 

• Information required to perform C^E tasks 

• Conununication capabilities to support the exchange of information [Ref 10]. 
Each of these have been previously described. Figure 4.4 shows this set of components 
and their relationships. C^Es have two kinds of resources: people and equipment. The 
degree to which people or equipment are employed depends on the degree of 
automation involved. 

2. Process 

The Data Flow Diagram (DFD) is the primary' tool used to illustrate the 
major components of the IDB and to systematically decompose major functions to 
their basic level. The function being described is the VIEO. Its elements include: the 
C^E. message, and link. 

a. Deriving C^Es 

C Es are identified by name, location within the organization, and by tasks 
they perform. Titles, such as "fire direction center," simultaneously identify the 
Element and give some idea of their function. These titles become progressively more 
descriptive, identifying branch and echelon (e.g. infantry' regiment fire direction center) 
and joint or combined level (including service and nation). A C“E is specified, then, by 
organization (or unit), branch, echelon, service, and country’. 
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(have) 

C: 

(perform) 





TASKS 






(require) 




(is exchanged by) 




Figure 4.4 Components of C Architecture and Their Relationships. 

The C"F is the processing component of the system. It performs a transfer 
function processing input and changing it to output. This process is illustrated in 
Figure 4.5. The Input-Process-Output (IPO) function is presented as both information 
and signal processing. 

b. Deriving Message Standards 

*) 0 

A C“F is viewed, then, as a C" system component whose function is to 
process inlormation. One C"F may receive raw intelligence information in an 
incoming message. This information is processed by extracting pertinent information 
in terms of an intelligence assessment. This assessment is then distributed to other 
C“Fs as an update in an outgoing message. The transfer function can be described in 
terms of the tasks being performed. An analysis of these tasks suggest the information 
required by the processing C“E. .A decomposition of a C‘F task results in a set of 
subtasks that retain the basic IPO structure at a lower level. Just as information 
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packaged in a message feeds the general task, information elements feed the C"E 
subtasks, these elements can be correlated with standard message elements. The set of 
message elements reflects the information requirement necessary for all the subtasks 
rellccted in the general task. By labeling this set, an appropriate message standard is 
specified. 

To illustrate the decomposition process, consider a hypothetical situation in 
which a tactical air operations center (TAOC) must alert a light anti-air missile 
(LAAM) battalion combat operations center (LAAM BN COC) to the possibility of 
engagement with enemy aircraft. The T.AOC must determine what message will convey 
completely the information required by the LAA.M BN. A tactical alert will invoke a 
set of procedures at the LAAM BN COC. 7 he COC must perform the subtasks listed 
in Table 5. These tasks govern the information required from the TAOC. Using the 
.Marine Corps .Message Element Dictionary (MED), standard elements of information 
can be derived, called Data Field Identifiers, 'Data Use Identifiers (Dl 1, DUT)(Shown in 
Table 6). 

If this particular combination of standard message elements is in the Marine tactical 
system's message inventory, it should be used. If not, the required elements are 
enumerated and submitted as a proposed standard for this particular tactical function. 



46 



I ABU; 5 

AIR ALIZRT SLI3 I ASKS 

SUBTASK NUMBER SUBTASK DESCRIPTION 

Subtask 1 assign a track number to the 

tactical alert 

Subtask 2 classify the alert in terms of Its 

track type 

Subtask 3 record the time of the event 

Subtask 4 classify the aircraft In terms 

of threat type 

Subtask 5 estimate flight size 

Subtask 6 record the bearing 

Subtask 7 record the range 

Subtask 8 record the altitude 

Subtask 9 record the velocity 

Subtask 10 Issue command instructions 



tabu: 6 

DU DLT BREAKDOWN 

INFORMATION ELEMENTS CORRESPONDING DFI/DUl 

Track number E618/001 

Track type E090/001 

Threat time C051/165 

Threat type E529/001 

Flight size estimate E901/001 

Track bearing E494/011 

Track range E499/003 

Track altitude E491/170 

Track velocity E233/001 

Command action E905/001 
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If the task description is incomplete, the user or cognizant doctrinal agency initiates 
action to correct it. This assures that operational requirements drive message 
standards. 

c. Deriving Link Standards 

Information is generally transmitted to a C E through an electronic signal. 
The message (Text) is entered into a converting device at the input, changed to 
electronic format and passed through a string of equipment to the next C^E. Here it is 
translated into the original textual form. Input and output requirements for each 
electronic device in the string are expressed technically as equipment specifications. 
Matching the input text to the output text specifies compatibility for the link. Figure 
4.6 characterizes the communications system and illustrates signal interface 
requirements. By correlating the specifications of a system with these standards, the 
signal interface requirements are satisfied. The technical specifications define the 
standard for the C E link. An occurrence of this link is recorded in the MEO. 




Figure 4.6 Communications System. 
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C"E links are usually constrained by the environment and context dictated 
in the mission requirement. These operational factors include determinants like range 
and security. These restrictions also help refine the technical specifications leading to a 
C^E link standard. Requirements are successively broken down into lower levels of 
detail through engineering analysis. If no system or equipment set exists to support 
the link requirement a circuit standard is adopted as a set of design specifications for 
the system. 

3. Network Construction 

The MEO is the basic network building block. A complete set of MEOs 
produces the C" Network. The proper association of MEOs is crucial to the 
construction of a network to be used as the model for conunand and control. While 
the MEO. by definition, describes a direct transfer of information, at times the 
exchange may transpire between non-adjoining C^Es. To accommodate this 
eventuality, the concept of a virtual message exchange occurrence (VMEO) is 
introduced. The VMEO denotes a path from the source C“E to the sink C^E through 
one or more intermediate C^Es. In essence the VMEO is simply a chained MEO as 
shown in Figure 4.3. 

Command and control flow diagrams (C^FDs), a specific application of data 
fiow diagrams (DFDs), are constructed using the doctrinal studies described in mission 
area analysis. The C^FDs represent pictorially the flow of activity in the network. 
Figures 4.7 and 4.8 combined with Tables 7 and 8 summarize the network design 
process. 

F. SUMMARY 

The interoperability database will provide a valuable tool for planners and 
managers to standardize description of the Marine Corps command and control 
architecture. Consistent application of the MEO concept in the IDB will help ensure 
interoperability and, at the same time, should reduce the procurement of redundant C^ 
systems. Driven by mission needs, the Technical Interface Concepts is in keeping with 
DoD direction discussed in Chapter II under Problem Formulation. The use of 
Message Exchange Occurrences follows closely the system bounding, process definition 
and integration modules of the MCES. Finally, the MEO description available in the 
IDB allows for data generation (Module 6) and aggregation following the outline of 
System Effectiveness Analysis which follows. 
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Figure 4.7 C^'FD for Direct Support Artillery Mission (DSAM). 
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tabu: 7 

Mi:0 SE l I OR DSAM 



MEO 


SOURCE C2E 


SINKC2E 


MESSAGE 


LINK 


1 


FO 


BTRY FDC 


CALL FOR FIRE 


VHF RADIO 


2 


FO 


BN FSCC 


CALL FOR FIRE 


VHF RADIO 


3 


BTRY FDC 


HOWITZERS 


FIRE CMD 


WIRE 


4 


BTRY FDC 


FO 


MSGTOOBS 


VHF RADIO 


5 


HOWITZERS 


BTRY FDC 


SHOT 


WIRE 


6 


BTRY FDC 


FO 


SHOT 


VHF RADIO 


7 


FO 


BTRY FDC 


ADJUST 


VHF RADIO 


8 


BN FSCC 


BTRY FDC 


CHECK FIRE 


VHF RADIO 


9 


BN FSCC 


FO 


CHECK FIRE 


VHF RADIO 


10 


HOWITZERS 


BTRY FDC 


RNDS COMPLETE 


WIRE 


1 1 


BTRY FDC 


FO 


RNDS COMPLETE 


VHF RADIO 


12 


FO 


BTRY FDC 


END OF MISSION 


VHF RADIO 
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Figure 4.8 Network Derived From MHO Message Set For DS.WF 
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lABLn s 

SUMMARY or NETWORK DESIGN PROCESS 



STEP 1; Establish the operational requirement. 

a. Establish the command and control requirement. 

(1) Identify C2Es by; 

(a) Name 

(b) Tasks 

(c) Location within the command and control structure 

(2) Draw C2FDs by; 

(a) Determining the sequence of activity for the 
mislon area 

(b) Classifying the Information passed from C2E 
to C2E In general terms 

b. Establish the general communication requirement. 

STEP 2: Construct an MEO 

a. Produce a message by; 

(1) Decomposing the C2E task Into elemental C2E tasks 

(2) Correlating the elemental C2E task with required 
Information elements 

(3) Correlating the Information elements with appropriate 
data eiements 

b. Identify connectivity from C2E pairs. 

c. Produce a C2E link by; 

(1) Deriving the link Interface requirements from the 
communications requirements 

(2) Decomposing the link Interface requirements Into 
technical specifications 

STEP 3; Design the Network. 

a. Specify the MEOs that comprise a C2E Interface 

b. Select equipment to Implement the C2E links 
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V. SYSTEM EFFECTIVENESS ANALYSIS 



A. INTRODUCTION 

The MCES, as described in Chapter II, provides a logical and orderly framework, 
for problem formulation, system bounding and specification of measures. The Marine 
Corps' Technical Interface Concepts (Chapter IV) characterizes the system and 
functions, and integrates them. Assigning the generic Communications measures 
(Chapter III) quantitative or qualitative values completes the first six modules of the 
MCES. What remains is to aggregate parameters and/or measures and then compare 
them to some desired state. System Effectiveness Analysis (SEA) focuses on the 
quantitative aspects of obtaining and evaluating measures. The steps of SEA can 
therefore be embedded in MCES, specifically in the last modules (Generation and 
aggregation). The following is a brief history of SEA provided the author by Dr. 
.Alexander H. Levis, Senior Research Scientist, Massachusetts Institute of Technology. 

B. BACKGROUND 

System EfTectiveness Analysis was first tested, starting in 1977, with funding from 
the Department of Energy (DOE) at Massachusetts Institute of Technology (MIT). 
The three year project focused on large power systems culminating in a final report 
(Pierre Dersin) during May 1980. Thesis works conducted primarily on command and 
control systems include; Bouthonnier (August 1982), Cothier (August 1984), Karam 
(January 1985), Bohner (May 1986), and Martin (August 1986). Other applications of 
the methodology include work on Flexible Manufacturing Systems (Washington - 
January 1985) and Assessment of Internal Combustion Engines (Levis, Haupt and 
.Andreadakis - 1985). 

C. SYSTEM EFFECTIVENESS ANALYSIS 

The description of SEA provided herein follows closely the work of Cothier 
(Ref 14: pp. 11-17] and Levis [Ref 15: pp. 2-11, 15-17]. 

The basic premise of the methodology is that a C^ system provides a service to 
the commander and his forces and, conversely, the commander establishes performance 
requirements for the system. Or, the C'’ system possesses a range of performance 
characteristics and the commander specific requirements based on his assigned mission. 
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The analysis assumes an ability to model both system capabilities and conrimander's 
requirements in terms having the same measure. This assumption is critical for without 
like dimensions, the evaluation falls apart. 

1. Concepts 

The integration of MCES and SEA is possible because both approaches are 
based on the same concepts. Specifically: system, emironmeni, context, design 

parameters, measures of performance, and measures of effectiveness. Of these si.\ only 
the term context has not been previously addressed (see Chapter II). The system and 
environment are defined within a particular context upon which the system cannot act, 
but which aflects the system. It describes the circumstances surrounding an event or 
situation. Figure 5.1 shows the relation. Figure 2.3 portrays the connection, derived 
for this specific application. 




Figure 5.1 System, Environment, and Context. 

2. Methodology 

The mission, system, environment, and context have been defined in Modules 
1 through 4 of MCES, and the Measures of Performance for a communication system 
described in Chapter III. The first step in SEA is to select the design parameters that 
influence each system MOP (also characterized in Chapter 111). Uy definition, these 
parameters are considered mutually independent, since they constitute the "independent 
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variables" in the analytical formulation of the methodology [Ref 15: p. 6]. The key 
word or element in step- one is system. 

The second step consists of defining parameters for mission requirements. The 
important words being mission and requirement. Levis indicates that this step, while 
implied in the feedback loop, is not explicit in MCES [Ref 15: p. 7], 

In steps three and four the chosen system and mission parameters are used to 
define MOPs and Requirements respectively. Each are expressed as functions of their 
parameters, i.e., 



MOPj(A') = f-(Xj....Xj^) (eqn5.1) 

where .Xj are the system parameters, Aj are Attributes or MOP's; and, 

Rj^ — ^m^'l""^n^ 5.2) 

where yj are the mission parameters and Rj^ are mission requirements. The issue of 
independence, previously addressed, is also applicable for the A's and R's derived from 
the formulation. Yet as dependent variables, they may be interrelated through use of 
common parameters. Hence. trade-olTs in one area may impact others. The results of 
these steps are specification of value(s) for both MOP and mission reflected as points 
or regions in their respective spaces. 

While both spaces may be of the same dimension, they could be defined in 
terms of different quantities or quantities scaled differently. Step five consists of 
transforming the dimensions into like quantities to be defined on a common coordinate 
frame. 

The system measures of performance are functions of system parameters. As 
the x's in equation (1) vary over their allowable range, so also do the MOPs generating 
a locus in the MOP space. The transformation from parameter to system locus is 
illustrated in Figure 5.2. Analagously, a set of values that satisfy mission requirements 
are mapped to form a mission locus (Figure 5.3). 

The seventh step is the key in analyzing effectiveness. In this step the system 
MOPs and mission Requirements are quantitatively compared through the geometric 
properties of the intersection of the two loci (step 6). These relations may take on 
either of two forms: 
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MOPj 



SYSTEM 

PARAMETERS 

if 




A 



CONTEXT £ 




Figure 5.2 System Locus. 



(1) The two loci do not have any points in common, i.e., the intersection of L,. 
and is null: 



's ^m ^ 



(eqn 5.3) 



In this case, the system does not satisfy the mission's requirements, and one would 
define the effectiveness to be zero, regardless of which specific measure is used (Figure 
5.4). 

(2) The two loci have points in common, but neither locus is included in the 
other: 



57 



MISSION 

PARAMETERS 

m 

0 



MODELS 

GAMES 

PLANS 




CONTEXT 




figure 5.3 Mission Locus. 



Lj. n X 0 (eqn 5.4) 

with 

Lj n < Lj and (eqn 5.5) 



In this case, a subset of the values that the .MOl’s may take satisfies tire mission 
requirements (figure 5.5). 
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f igure 5.4 Form One. 




Figure 5.5 Form Two. 

Many diderent measures can be used to describe the e.xtent to which the system meets 
the requirenieius. Each of tliese measures may be considered an MOIF For example, 
let T be such a measure. Then an elFeetiveness measure can be del'ined by 
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(eqii 5.6) 



which emphasizes how well the system capabilities are used in the mission, while 



expresses the degree of coverage of the requirements by the system capabilities. 1 wo 
special cases of the intersection include: 



In this case, it follows from Equation 5.8 that 1.^. is larger than and. consequently, 
the ratio defined by liquation 5.6 will be less than unity. 'Ihis result can be interpreted 
in two ways, first, only certain system attribute values meet the requirements of the 
mission. The second interpretation is that the use of this system for the given mission 
represents an inelTicient use of resources since the system capabilities exceed the 
mission requirements. Inelliciency. in turn, implies lower eirectiveness (I'igure 5.6). 
.Mternatively, 




(eqn 5.7) 




(eqn 5.8) 





A 



I'igure 5.6 Form fwo, Case .'\. 
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(cqii 5.9) 




The system locus is entirely contained in the mission locus which might imply that the 
system completely satisfies the mission requirements. However, there are ranges of 
mission requirements not satisfied by the system (figure 5.7). 



The measures of ellectivcness given by liquation 5.6 or liquation 5.7 are 
partial measures. Let these partial measures be denoted by {Hj.). To combine these 
into a single global measure, utility theory may be used. 'Iherefore, the subjective 
judgements of the system designers and the users can be incorporated directly into the 
methodology in two ways: (1) by choosing dilferent partial measures, and (2) by 
selecting a utility function. The global cirectivencss measure is obtained, finally, from 



This is the last step of the SlIA methodology and corresponds to the seventh modulo of 



2 




A 



Figure 5.7 Form Two, Case B. 



E — u(Ej, E-) 



(eqn 5. 10) 



the MCES. 
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D. COMMENTS 



A graphic representation of the System Eifectiveness Analysis methodology is 
shown in Figure 5.8. This presentation implies, as has been stated, that .Mission and 
system parameters are derived independently. This aspect of SEA and .MCES 
procedures is in keeping with the OlTice of Management and Budget (OMB) 
requirement to express requirements in mission terms [Ref 5]. This represents a goal 
to which all acquisition managers should subscribe. Through successive iterations of 
each process both parameters are adjusted to construct an elTicient; effective structure. 
The mission requirements will normally represent a 'first-cut' or goal for the system. 
The system attributes describe contractor or other technical capabilities to meet the 
mission requirements. Examination of the diflerences allows for redefining goals or 
'forcing' technological progress. Broad disparities may also cause project termination 
before additional resources are spent on an imprudent venture. 

This presentation of SEA may suggest the necessity to quantify and describe 
measures in two or three dimensions. In fact SEA has w'orked command and control 
problems in up to seven spaces. In such cases, two and three dimensional decision aids 
are prepared after careful consideration of the processes involved in w’orking each 
measure. Limiting or forcing the use of only two or three measures in the evaluation 
causes a loss of information and may adversely affect the decision process. 

Finally, it seems apparent to this author that of all the modules of MCES the 
quantitative aspects of module seven needs additional elTort. Detailed mathematical 
descriptions, beyond the scope of this thesis, are required to relate, generically, the 
conununications processes inferred in Chapter 111 (Measures). System ElTectiveness 
Analysis provides the logical framework for expansion in this area. 
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SYSTEM CONTEXT MISSION 



Figure 5.8 



Tlie Mctliodology of System LlFcctivcncss Analysis. 
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VI. EXAMPLE APPLICATION 



A. INTRODUCTION 

This chapter serves to demonstrate application of the tools previously described 
in the acquisition process. The problem addressed is purposely simple allowing, 
especially in the aggregation module, a graphic portrayal of the analysis process. 
Analysis of a more complex system would be much more involved requiring a detailed 
understanding of engineering, mathematics, and decision theorv’, beyond the scope of 
this thesis. 

B. DESCRIPTION 

An architectural evaluation of a large command and control system has been 
conducted to assess the system effectiveness in light of a recently conducted Mission 
.Area Analysis (MAA). The outcome of the study indicated that the communications 
element of the architecture was vulnerable to current and projected enemy electronic 
warfare (EW) platforms. The following sub-sections outline the steps taken to 
formulate alternatives for the decision making process using the tools discussed in 
Chapters II-V. Database considerations are separately noted at the end of each sub- 
section. 

1. Problem Formulation 

A requirement exists within the system to transmit data among units. This 
process is interrupted when an enemy jammer disturbs the link. 

Intelligence sources indicate an enemy jamming presence capable of emitting 
both UHF and SHF broadband noise. The UHF emitter uses a 5db gain crossed 
dipole antenna and the SHF, a 42db dish antenna. Both transmitters can generate up 
to 1000 Watts of output power. The jammer operates from an airborne platform; 
however, because of friendly air suppression, can approach ground based sites no 
closer than 200 miles. This estimate represents projected capabilities spanning the next 
ten years. 

Database considerations: None specific to this module. 

2. C“ System Bounding 

The physical entities of the system are described as Units Alpha and Bravo. 
These two command and control elements (C^Es) are first verified to be elements in 
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the data base and then used to ascertain structure (organization hierarchy and 
information (low patterns). While Unit Alpha is (bund to be hierarchically senior to 
Bravo, the information How patterns indicate two-way, proportional dialogues; hence, a 
requirement for full-duplex communication. The bounding process also highlights 
digital vice analog transntission at a data rate of 1200 bps for the current terminal 
devices and 2400 bps upgrades during the next decade. Units Alpha and Bravo operate 
no closer than 200 and no further than SOO miles apart. The physical depiction of the 
bounding process is shown in Figure 6.1. 

Database considerations: If a C‘‘E is not found in the database, then 

justification for inclusion is compiled and submitted to the database manager for 
action. 




The C^Us and the most basic link requirements were described in the 
'bounding' module. Following the MCES and Marine Corps descriptive processes, 
outlined in Chapters II and IV, it is now necessary to derive the message standards (or 
process function) prior to system integration. This section borrows from the 
architectural process definition conducted (assumed) prior to this communications 
system study. During the previous evaluation, the environmental 'initiator' of the 
process, the internal C~ mechanisms, and the desired outputs were manipulated and 
appraised over varying scenarios or contexts. C“E tasks and information requirements 
are generated and used to specify the message standard(s). Tasks are decomposed into 
subtasks. The subtasks specify message elements which are described in the Message 
Elements Dictionary' (MED) as Data Field Identifiers; Data Unit Identifiers 
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(DFI DUIs). This functional decomposition describes, alphanumerically, the conmiand 
and control process of interest. 

Database considerations: Specific DFfDLTs are assumed to exist in the 
database. If the database is missing these identifiers, justification is provided to have 
them included. 

4. Integration 

The bounded system (C^Es and links) coupled with required processes 
(messages) forms Message Exchange Occurrences (MEOs). These MEOs are analyzed 
and used to depict the overall requirement in the form of a command and control How 
diagram (C^FD)(Figure 6.2). The MEO (or set of VIEOs) is then compared with 
existing standards using the interoperability database. For purposes of this 
explanation, the C^Es and message standard elements exist as specified in the MEOs. 
The link standards, while similar, will vary as a result of friendly and threat 
technological change. The database (MEOs) will be used, however, for initial system 
evaluation. This process allows analysis of existing systems prior to specification of 
new hardware or software requirements, thus verifying that changes are necessary to 
meet the mission objectives specified in Module 1. 

Database considerations: Assuming, as in this case, that the C^Es and 

DFI, DUIs exist in the database, and that link standards exist for the system under 
consideration, once a new communications system is developed, a means must exist for 
difierentiating between the former and current MEOs. As long as the older links are in 
use, a distinction is necessary for the new parameters. 

5. Measures of Performance 

While all of the generic measures described in Chapter III may be applicable, 
this analysis will focus on speed, survivability, and llexibility. 

Database considerations: The database may contain information pertaining to 
previous evaluations. This information should include any measures used in 
conducting the study. 

6. Data Generation 

The performance of the communications system must be ascertained using (a) 
data generation technique(s) (see database considerations). The system itself must 
meet the following requirements: 

• speed: 1200 to 4S00 bps 

• survivability: 10'^ to 10'^ BER 

• flexibility: ability to operate varying bit rates over the required range 
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Figure 6.2 Integration Depiction. 

The speed requirement meets both current and anticipated (1200-2400bps) terminal 
capabilities. The additional 2400bps allows engineers llexibility in design, yet caps 
available speed avoiding spending for unnecessaiy capacity. I he Bit-Error-Rate (BER) 
specifications should meet current and planned needs and also set an upper limit on 
expenditures. The flexibility measure is subjective. It is included for the decision 
maker to choose between identical or nearly identical systems proposals. 

Database considerations: This data is based on both subjective judgement and 
specifications available for the current system (found in the IDB). 

7. Aggregation of Measures 

The final module addresses synthesis of the mission requirements and then 
compares existing and proposed systems with these baseline (ntission) needs. The 
aggregation process will use the descriptive tools of Systems Effectiveness .Analysis 
(SE.A)(Chapter V) to ensure requirements are met. 

Database considerations; The final check on whether the system meets 
mission requirements is conducted by verifying the completion of all MEO tasks and 
subtasks. 
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C. ANALYSIS 



As stated in the thesis introduction, this section assumes knowledge of 
communications engineering principles. The following additional assumptions apply to 
the system analysis; 

1) Operating distances and jammer standoff will remain the same over the project 
life-cycle. 

2) The jammer will always be able to work within the footprint of the satellite 
antenna and outside the range of friendly air-suppression systems. 

The system currently in use will help determine a baseline for the analysis. An 
AN/TSC-l is used at Unit Alpha and an AN/GRC-1 at Unit Bravo. Tables 9 and 10 
outline their respective specifications. The system uses a geostationary full processing 
satellite as a relay platform described in Figure 6.3 and Table 11. 



TABLE 9 

TSC-1 SPECIFICATIONS 
(Tactical Satellite Communicationsi 



Frequency: 


SHF (7.5-8.5 Ghz) 


Antenna: 

Transmitter: 


10 meter parabola 
Sidelobes, -30 db 


Power Amplifier: 


8000 Watts 


Receiver: 


GfT 


14 db 


Modulation: 


Spread Spectrum 
PSK 


(5 Mhz chip rate) 


Data Rates 


75,150,300,600 
1200 or 2400 bps 



Figure 6.4 highlights the current performance based on the specifications 
previously addressed. As evidenced by the performance line, outside the bounds (data 
generation) of the desired requirements, the existing system does not meet the 
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'lABLI; 10 

GRC-1 SPi:CiriCAIIONS 



(Ground R adio Communications) 



Frequency 


UHF (225-400 Mhz) 


Antenna 

Transmitter: 


Inverted Discone 
Gain = 9db 


Power Amplifier 


100 Watts 


Receiver; 


Noise Figure 


6db 


Modulation: 


Frequency hop 
PSK 


Hop Bt = 175Mhz 


Data Rates 


75,150,300,600, 
1200 or 2400 bps 




I'igure 6.3 Satellite Block Diagram. 



69 





TABLE 11 




SATELLITE TECHNICAL PARAMETERS 


Uplink 


SHF 


liHE 


Antenna; 

G/T: 

Channel Carrier 
Receiver Bandwidth 


Horn (Gain = 29 db) 

0 db 

8Ghz 

10 Mhz (Spread) 


Crossed dipole (Gain = 4 db) 

-26 db 

Hopped 

Hopped (225-400 Mhz) 


Downlink 


$HF 


gHF 


Antenna; 

Power; 

Channel Canier 
Transmit Bandwidth 
Modulation 


Horn (Gain = 29 db) 
TWTA (40 Watt) 

8.3 Ghz 

10 Mhz (Spread) 
PSK 


Helix (Gain « 9 db) 

Solid State (200 Watt) 
Hopped 

Hopped (225-400 Mhz) 
PSK 



standards. It now remains to further refine the mission performance space in order to 
assure that request for proposal (RFP) specifications give designers an accurate 
description of requirements and channelize their efforts in keeping with budgetary 
limits and mission requirements. The mission requirements relate performance as a 
function of data rate and bit-error-rates. The budget lintits are constructed given cost- 
performance data. 

Figure 6.5 illustrates a hypothetical cost-performance curve for this 
communications system. While any number of curves may be realistic in this 
application, lacking actual data, this curve represents the author's opinion that as 
performance improves, cost increases at an increasing rate. Inasmuch as future 
terminal applications will push the communications system past current technology, 
research and development costs will increase. By keeping cost performance in line with 
budget constraints, an upper limit in the mission space can be generated. Such a limit, 
when applied to Figure 6.4 may look as projected in Figure 6.6. The line indicates that 
as performance increases it will cost more for the system. At lower speeds (1200bps) 
adding funds will produce more significant gains in bit-error-rate; whereas, at higher 
speeds (4S00bps) a similar addition of lunds nets less improvement in BER. 
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Figure 6.4 System Performance. 
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Figure 6.5 Cost-i’crformance Curve. 
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Figure 6.6 System Performance with Cost Line. 

Systems planners and engineers have indicated that current terminal equipment 
requires a 10*^ BER @ 1200bps and no worse than 10'^ BER @4S00bps to sustain 
desired thruput in current and future applications. While thruput is used as a measure 
in both mission and cost line determinations, the mathematical formulation of inputs 
will vary. Hence, the BER line (mission) will not be parallel to the cost line previously 
addressed. Both limits assume a linear relationship that may or may not exist. 1 he 
BER limits line is shown in Figure 6.7. This line indicates the minimum acceptable 
performance to meet mission requirements. 

A realistic estimate of the mission space based on speed and survivability is 
compiled in Figure 6.8 by combining Figures 6.4 through 6.7. This picture gives the 
designer a more definitive, measure oriented description of the desired system. It also 
focuses the analysis and decision process, in that alternative systems outside the shaded 
area 'C' are either too expensive (area 'B') or unacceptable given the threat and 
terminal requirements (area 'A'). Figure 6.8 highlights the fact that the original 
(bordered square) requirements space (10‘ to 10 BER and 1200 to 4800bps) allowed 
too much leeway in the system design process. 
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rigure 6.7 System I’crformancc with UHR Limits. 
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rigure 6.S Mission reilbrmance Space. 
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D. SUMMARY 



This chapter has demonstrated, through analysis of a simple project, use of the 
tools previously explained in this thesis. Several comments relative to the analysis are 
in order. 

The communications system of interest was made purposely simple to 
demonstrate flow between the modules of MCES and to highlight the supplementary 
tools from which the modules are filled. A detailed explanation of cost-performance 
analysis is beyond the scope of this thesis, hence the cursory examination in Section C. 

.Another area intentionally omitted is a detailed examination of the measures 
chosen for this application. Again, the measures chosen are used to demonstrate the 
methodology, not to define hard-and-fast guidelines for analysis of like systems. .As 
previously explained, many measures could have been included in the analysis. This 
would have required a detailed study of not only the source of data, but also the 
mathematical manipulations necessar>’ to present the information in understandable 
form. As mentioned in Chapter V, the modelling of parameters to create or support 
measures of performance or effectiveness is perhaps the hardest concept in this 
collection of tools to deduce or to comprehend. 

Finally, the decision process has been omitted. The intent of this work is to 
explain and provide an easily understandable framework within which acquisition 
projects can be evaluated short of an actual decision. The decision process is multi 
faceted, as highlighted in Chapter II. The information provided in Figure 6.8 will be 
useful in framing this effort. 

The project manager or decision authority has refined the original data generated 
in .Module 6 to the point where a viable mission space has been created. Alternative 
communications systems that fit or more closely fit the space may provide a logical 
choice for contract award. As an example, if the receive antenna gain (Gr) were 
adjusted to 10 or lldb, new system curves, relative to the mission space, can be created 
(Figure 6.9). Such an adjustment may provide additional direction to engineers or 
validate the alternative system's claim to requirements satisfaction. 

It is not certain from the information provided what percentage of compliance 
with the mission requirements is met by any of the alternative systems. The 
intersection of the 'system performance line' with the mission space is in actuality a 
collection of points, which, mathematically, cannot be assigned a percentage 
compliance. This highlights a potential problem with presentation of requirements in 
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cither two or three-dimensional space. W'hile tlie picture gives a more ticcuraie 
description of desired ranges, it sliould not. at least in this application, be used to fully 
evaluate the project. The implication here is that if the system line falls in hand C ". 
then it meets the stated requirements and must be selected. Since none of the systems 
lall completely within the band, presumably no selection can be made. Had the 
evaluation been conducted using additional measures, the possibility of answeritrg the 
mission requirements may have been enhanced insofar as the pictorial presentation is 
concerned. Ultimately, if the constraints, as functions of other parameters, arc allowed 
to vary, a more dynanric decision process is created. Stated otherwise, by adding more 
dimensions (measures), the possibility of compliance with rcHiuiremcnts or tradcolfs 
within the mission bounds is improved. The project mtmager must define the 
judgement criteria, in percentages or otherwise, as part of the decision process and 
provide this criteria in the request for proposal (RTP). specifically in the statement of 
work (SOW). 




Figure 6.9 .Alternative Communication Systems. 
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VII. CONCLUSIONS/RECOMMENDATIONS 



A. SUMMARY 

This thesis has described and explained the use of four tools reconunended for 
project managers when procuring communications systems. The Modular Command 
and Control Evaluation Structure (MCES) provides the framework for this approach. 
It is used initially at the architectural level to evaluate the command and control 
system of interest. Depending on the application, this process may start globally at the 
National Command Authority (NCA) level, working successively through the 

conunand hierarchy to a particular C^ system. At the C^ system level, 

communications, weapons systems, intelligence sources, displays, and computer devices 
are evaluated as to their contribution to the effectiveness of the C system. 

Three tools have been discussed as means by which the modules of MCES are 
implemented. Generic measures of performance, 'elTectiveness for the communications 
system have been described. Marine Corps Technical Interface Concepts have been 
used to bound the problem, define the C^ process required of the bounded structure 
and then integrate the system elements and functions. The Marine Corps 

interoperability database (IDB) is proposed as a source for data to quantitatively 
describe the generic measures specified for the system. The third tool. System 

Effectiveness Analysis (SEA), serves to assist in the data generation process and to 
analyze and refine (aggregate) the chosen measures bounded by mission needs and 
budgetary constraints. All of these means serve as aids in the decision process. 

B. CONCLUSIONS 

Use of a structured approach in the evaluation and acquisition processes helps 
ensure that all dimensions of the problem are considered, common terms, definitions, 
and procedures help managers understand the process they are directing and assists 
decision makers by presenting facts and alternatives in a common format. The 
existance of databases of information pertaining to structure, processes and 
specifications will help managers to evaluate existing systems. The manager can also 
use this common source of data as a baseline in exploring future applications. 
Continued application of these tools, relative to the database, will sustain maintenance 
of the information contained therein, helping to assure accurate future assessments. 



76 



C. RECOMMENDATIONS 



Work on this thesis has suggested to the author five areas of potential study 
relative to the processes described. 

First, concerning problem formulation. Mission Area Analysis (MAA) is 
presently used to deterntine the need for system evaluation. An explanation of the 
methodology of MA.A would enhance the problem formulation module of MCES. 

Second, the generic measures presented herein are the author's interpretation of 
significant performance requirements for a communications system. Review of other 
documents suggests additional measures are applicable. For example, availability and 
ntaintainability may be specific measures, rather than criteria dependent on reliability. 
.An elFort needs to be made to refine the measure selection process. .As has been 
suggested in this thesis, the parameters used to discern measures of 
performance elTectiveness may be the same; however, formulation of the specific 
criterion is dilTerent allowing measure independence. The interoperability database 
suggest one means wherein this issue of independence can be evaluated. 

Third, this thesis has suggested use of the interoperability database as a means 
whereby baseline systems can be defined for the analysis process. Modeling of the 
system with all of its elements (people, processes, and equipment) has been suggested 
but not described. 

Fourth, it has been submitted that the collection of tools illustrated herein serve 
as an aid to decision makers; however, little has been written on the subject of the 
decision process. .An understanding of the means and psychology of decision making 
is critical to presentation of viable alternatives that support mission need. 

Finally, a simple example has been used to demonstrate the utility of a collection 
of tools in standardizing the acquisition and evaluation processes. Successive 
applications with existing and proposed architectures will ultimately validate the 
usefulness of this framework. 
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APPENDIX A 

DICTIONARY OF ACRONYMS AND TERMS 



BER 


Bit-Error-Rate 


BPS 

C^ 

C-E 

C“FD 

C^l 


Bits-Per-Second 

Command and Control 

Command and Control Element 

Command and Control Flow Diagram 

Command, Control and Communications 

Command, Control, Communications and Intelligence 


C SCSC 


Cost Schedule Control Systems Criteria 


CBR 


Chemical, Biological, and Radiological 


CDR 


Critical Design Review 


Cl 


Configuration Item 


COC 


Combat Operations Center 


CO MS EC 


Communications Security 


D,V 


Demonstration, Validation 


DFD 


Data Flow Diagram 


DFI 


Data Field Identifiers 


DoD 


Department of Defense 


DOE 


Department of Energy 


DSAM 


Direct Support Artillery Mission 


DSARC 


Defense System Acquisition Review Council 


DTC 


Design to Cost 


DU I 


Data Unit Identifiers 


ECCM 

EMP 


Electronic Counter Counter Measures 
Electromagnetic Pulse 


EW 


Electronic Warfare 


FCA 


Functional Configuration Audit 


FO 


Forward Observer 


FSCC 


Fire Support Coordination Center 


FSD 


Full Scale Development 


GOS 


Grade-of-Service 


IDB 


Interoperability Database 
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IMP 


Interoperability Management Plan 


IOC 


Initial Operational Capability 


IPS 


Integrated Program Summary 


JCS 


Joint Chiefs of Stall 


JINTACCS 


Joint Interoperability of Tactical 
Conunand and Control Systems 


JMSNS 


Justification for Major Systems New Start 


JRMB 

JTC^A 


Joint Requirements Management Board 
Joint Tactical Conunand, Control, and 
Conununications Agency 


LAAM BN 


Light Anti-Air Missile Battalion 


LCC 


Life Cycle Cost 


LPE 


Low Probability of Exploitation 


LPI 


Low Probability of Intercept 


MAA 


Mission Area Analysis 


MAGTF 


Marine Air Ground Task Force 


MCES 


Modular Conunand and Control Evaluation Structure 


MEO 


Message Exchange Occurrence 


MIT 


Massachusetts Institute of Technology 


MNS 


Mission Need Statement 


MOD 


Measure of Design 


MOE 


Measure of EfTectiveness 


MOPE 


Measure of Force EfTectiveness 


MOP 


Measure of Performance 


MOPE 


Measure of Policy EfTectiveness 


MORS 


Military Operations Research Society 


MTACCS 


Marine Corps Tactical Command and 
Control Systems 


MTBF 


Mean Time Before Failure 


MTS 


Marine Tactical System 


MTTR 


Mean Time To Repair 


NASA 


National Aeronautics and Space Administration 


OFPP 


OfTice of Federal Procurement Policy 


OJCS 


Office of the Joint Chiefs of Staff 
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0MB 


Onice of Management and Budget 


OPFAC 

p3i 


Operations Facility 
Pre-planned Product Improvement 


PCA 


Physical Configuration Audit 


PDM 


Program Decision Memorandum 


PDR 


Preliminary Design Review 


POM 


Program Objective Memorandum 


PPBS 


Planning Prograntming and Budgeting System 


PRR 


Production Readiness Review 


RDT&E 


Research, Development, Test & Evaluation 


RF 


Radio Frequency 


RFP 


Request for Proposal 


SARC 


System Acquisition Review Council 


SCP 


System Concept Paper 


SDDM 


Secretary of Defense Decision Memorandum 


SDR 


System Design Review 


SE 

SEA 

SECDEF 


System Engineering; or. Support Equipment 
System Effectiveness Analysis 
Secretary’ of Defense 


SHF 

SNR 


Super High Frequency 
Signal-to-Noise Ratio 


SOW 


Statement of Work 


SRR 


System Requirements Review 


TDS 

TIC 


Tactical Data System 
Technical Interface Concepts 


TIDP 


Technical Interface Design Plans 


TRI-TAC 


The Joint Tactical Communications Ofiice that preceded 
establishment of JTC^A. 


UHF 


Ultra High Frequency 
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APPENDIX B 
ACQUISITION POLICIES 



1. INTRODUCTION 

The process of acquiring new government systems is complex. While no single 
source describes all of the management principles involved in a product's life cycle, the 
following excerpt from Reference 16 (pp. 1-1 thru 1-5) provides a good overview of the 
chronology and requirements for governmental procurement. The processes remain 
essentially the same; however, several structure changes, made since the reference was 
published, are worthy of note. The DS.<\RC (Defense System Acquisition Review 
Council) has been replaced by a Joint Resources Management Board (JRMB); and. the 
Defense Acquisition E.xecutive (D.AE) is now the USD(A), Undersecretarv’ of 
Defense(Acquisition). a new post created in 1986. 

2. APPROACH 

a. Government Acquisition Policies 

Over the past several decades, as large systems have evolved and matured, the 
problems encountered in the management of these systems have caused the DoD to 
develop a systematic engineering management process that directs periodic review and 
control of the program throughout its acquisition and operational life. In the early 
1970s. the Office of Federal Procurement Policy (OFPP) was established to provide 
policies, methods, and criteria for the acquisition of property and services for all 
executive agencies. In 1976 the Office of Management and Budget (O.MB) Circular 
.A-109 was published. The philosophy behind 0MB Circular A- 109 is for the 
Government to become a more reliable customer by standardizing its acquisition 
policies throughout the Government by avoiding major contract delays and 
cancellations, and to promote an unbiased concept definition. It requires that the 
Government operating agency establish and justify a valid requirement for a capability, 
which must be approved by the executive agency head (Secretaiy of Defense, NAS.A 
.Administrator, etc.) before involving industry in the system acquisition process. The 
approval of this needed capability also establishes the priority and theoretically the 
availability of resources to fulfill the need. 
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Approval of, for example, a DoD Justification for Major System New Start 
(JMSN’S) or a NASA Mission Need Statement (MN'S) initiates the acquisition cycle. 
Circular A- 109 requires that this need be recertified by the agency head upon approval 
of a selected design concept for test and demonstration, again before committing the 
system to production. The acquisition process may be terminated at any of these 
decision points. The DoD approach to be followed using A-109 includes: 

• Prototyping and early demonstration to reduce risk 

• Program control and ritualized review by the Defense System .Acquisition 
Review Council (DSARC) 

• Placing of emphasis on tradeoffs between cost, performance, schedule, and risk. 

In May 1981, then Deputy Secretary^ of Defense (SECDEF) Frank Carlucci 
proposed a number of changes which became the DoD Acquisition Improvement 
Program and included: 

• Revising DS.ARC reviews to decentralize responsibility 

• Encouraging capital investment to enhance productivity 

• Seeking earlier IOC for less ambitious goals, update later 

• Incentivizing reliability and maintainability 

• Structuring contracts to consider risks shared by Government and contractor 

• Putting more emphasis on credibility rather than lowest bid 

• Reducing cost and time to procure small items by raising thresholds for direct 
PrograniT OlTice and cost data reporting 

• Reducing requirements for socioeconomic program burdens 

• Making more realistic cost estimates and higher front-end funding 

• Permitting purchases with multiyear contracts 

• Promoting the use of Pre-Planned Product Improvement (P"^!). 

As a result of his actions and the subsequent review and approval process, 
eight decisions have been made that directly affect the DSARC process: 

• DS.ARC decision milestones are to be reduced to Requirement Validation 
(Milestone I) and Program Go-Ahead (Milestone II). 

• The criterion for DSARC review is increased to S200 million in Research, 
Development, Test, and Evaluation (RDT&E) and SI billion procurement in 
FY80 dollars. 

• The, DS.ARC briefing and data requirements are decreased to increase the 
efiiciency of DSARC and other program reviews. 

• The appropriate service Secretary or Chief in included in the DS.ARC 
membership. 

• The Under Secretarv of Defense for Research and Engineering (L'SDRE) 
remains the Defense .Acquisition Executive (D.AE). 
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• Integra tion of the DSARC and the Planning Programming, and Budgeting 
Svstem (PPBS) process js acconmiodated bv requircmg that fiscallv executable 
programs be presented for DSARC review. 

• The JMSNS is to be submitted with the service Program Objective 
Memorandum (POM) to initiate a new program. The JMSNS defines the 
mission need, identifies boundarv conditions, aJid provides an initial acquisition 
strategy outline. 

In March 19S2 DoDD 5000.1, Major Systems Acquisition, was revised to 
rellect the following acquisition management principles and objectives: 

• Ensure elTective design and price competition 

• Improve system readiness and sustainability 

• Increase the stabilitv in acquisition programs through eHective long-range 
planning, use of evollitionan.’ alternatives instead of solutions at the frontier of 
technologv. realistic budgeting and funding of programs for the total life cvcle, 
and planning to achieve economical production rates 

• Delegate authority to the lowest levels of the service that can provide a 
comprehensive review of the program 

• Achieve a^cost-elTective balance between acquisition costs, ownership costs, and 
system effectiveness in terms of the missions to be performed. 

b. System Life Cycle 

The life cycle for a typical major DoD system acquisition is depicted in Figure 
A.l, showing both the previous and current practice. The NASA life cycle combines 
the elements of the DoD conceptual and validation phases into one phase and 
envisions no production phase; operational and deployment phases are comparable. 
Regardless of nomenclature the purpose is the same; from establishing the need to 
placing the system into operation. System Engineering is an iterative process whereby 
individual aspects of the program, such as design, costs, or risks, for example, are 
successively reviewed at the designated milestones and the need recertified before 
additional resources are authorized by the reviewing authority for the continuation of 
the program. Any DoD milestone decision will be made by the SECDEF only after a 
formal review or audit of the contractor effort by Government Program OtTice 
personnel. These reviews, which increase in depth of detail as the system life cycle 
progresses, form the basis for the presentations that Government program managers 
will use to justify further development of the program. It must be emphasized that for 
an actual program, the agency head must decide either to continue the present phase, 
proceed to the next phase, or cancel the program. The SecDef can also direct a DoD 
Program to omit Demonstration-Validation and proceed with Full Scale Development. 
A similar cycle is required for "less than major systems," but with Service or Major 
Command Milestone approval instead of DoD. 
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Figure A.l Major DoD System Life Cycle (Ref DoDD 5000.1). 

7. Concept Exploration (C£) Phase 

Concept Exploration (CE) is initiated with the approval of the service 
POM, which includes the J.MSNS by the SECDEF, who signs the Program Decision 
Memorandum (PDM). It extends to the program decision that authorizes 
accomplishment of either Demonstration/Validation or Full Scale Development phases. 
Approval by SECDEF is contingent upon the DoD component having sulFicient 
reserves to complete concept Exploration. This phase defines and selects system 
concepts for further development. Most activity during this phase is an internal 
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Government responsibility; however, several parallel short-term contracts are required 
by 0MB circular A-109 to promote the most cost-efTective solution. The output from 
the contractor efi'ort must define performance envelopes, identify risks, present 
preliminary alternative design concepts, and determine the production feasibility of the 
design, with schedule estimates and a preliminary Life Cycle Cost (LCC) estimate. 
These will be used by the Government to establish a functional baseline, usually in the 
form of a Type A System Specification (Ref MIL-S fD-490). The output should also 
contain a proposed Request for Proposal (RFP) for the Demonstration Validation 
phase. The output from these contractor elTorts is revievv'ed by Government program 
management for adequacy. A System Requirements Review (SRR) may be 
accomplished here or very early in the Demonstration, Validation phase. Following 
this. Government and contractor efTorts are combined into a System Concept Paper 
(SCP) which contains an updated needs statement, a description of alternatives with 
performance estimates, an acquisition strategy, a program structure management plan, 
and a risk assessment. The SCP is the basis for review and decision to proceed into 
further program phases. The SCP is reviewed first by the service component System 
Acquisition Review Council (SARC) and. if approved, the DSARC. This review 
constitutes Milestone I. 

The DS.VRC reconfirms the need, determines that risks are adequately 
considered and that program structure, technical planning, and LCCs have been 
established. When the SCP meets all objectives, it is forwarded to the SECDEF with 
recommendations to proceed to the Demonstration, Validation or Full Scale 
Development phase. Approval by SECDEF is documented in a SECDEF Decision 
Memorandum (SDDM) and authorizes the service to prepare and release an RFP. The 
RFP contains the functional baseline, management approach, and the Statement of 
Work (SOW) that describes the scope of the contractor elTort for the approved phase. 

2. Demonstrationf Validation {Dj fO Phase 

The Demonstration Validation (D,'V) phase is initiated by the release of an 
RFP by the Government. After proposal evaluation and contract award, the System 
Engineering (SE) becomes a contractor efibrt, usually by two or more contractors. 
The D, V competitive environment may be maintained through Full Scale Development 
(FSD). The objective in the Validation phase is to deterinine whether to proceed with 
FSD. The output of this phase should establish firm and realistic performance 
specifications (allocated baseline) that meet the operational and support requirements 
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of the contract SOW. This allocated baseline, which is also described as a design 
requirements baseline, incorporates technological approaches proposed to satisfy 
requirements established by the functional baseline. As the System Engineering 
process progresses from the functional to the allocated baseline, required configuration 
Items (CIs) are identified. The process includes trade studies to ensure that the system 
being defined satisfies the functional baseline and the SOW requirements with the best 
possible balance of LCC and Design to Cost (DTC) requirements, schedule, and 
operational elTectiveness. In addition, continual risk assessment of the elements of the 
proposed system will be made to identify areas of uncertainty that must be overcome 
in later program phases. Components whose performance is critical to program 
success may be prototyped to minimize risk. A System Design Review (SDR) will be 
held at the end of this phase (or early in the FSD phase) to provide a preliminary 
allocation or requirements to hardware and software CIs, personnel, and facilities. 
This system design will normally be supported by a proposal for the FSD phase, 
including program management plans. A Decision Coordinating Paper (DCP) and 
Integrated Program Summary (IPS) are prepared by the Government Program Office 
for review by the SARC(s) and DSARC. If all requirements are satisfied, a Ratified 
DCPTPS recommending approval is forwarded to SECDEF. A SECDEF approval 
authorizes contract awards for the next phase. 

3. Full Scale Development (FSD) Phase 

To initiate the FSD phase, the Government negotiates a contract with one 
or more contractors. The purpose of the FSD phase is to ensure that detail design is 
complete, major problems have been resolved, achievement of performance 
requirements has been demonstrated by testing, and the designed system is producible. 
The type of contract is dependent on perceived program risks, but usually a 
development contract is a cost-plus-incentive type to encourage innovation and 
tradeolTs when technical and engineering problems are uncovered in this phase. 
Continual risk assessment is characteristic of the FSD phase. A cost-type contract 
award will require the contractor to operate a management system that satisfies 
Government Cost Schedule Control Systems Criteria (C,SCSC)(Ref MIL-STD-881). 
The FSD design activity is based on Part I specifications (Type B, Ref MIL-STD-490) 
and System Engineering documentation, with changes directed by the approved DCP, 
as the basis for design. 
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The Preliininan' Design Review (PDR) is held after preliniinan.' design 
effort, but before the start of detailed design. It provides authentication of the Part I. 
Type B {MIL-STD-490) development specifications. The Critical Design Review 
(CDR) is conducted for each Cl before release of the design for production. These 
reviews may culminate in a system CDR which reviews the completeness of preceding 
CDRs and ensures adequacy of interfaces. 

The FSD phase provides verification of performance capability before 
operational use by testing the system or equipment in its intended environment. The 
results of this testing and any proposed changes, reftirbishments, and corrected 
deficiencies are evaluated in a series of reviews and audits intended to provide 
confidence that the system has been developed sufficiently to proceed with production 
for operational use. 

The Functional Configuration Audit (FCA) is conducted on each Cl before 
acceptance of the development effort. The Cl must represent the configuration 
released for production and demonstrate compliance with the Part I development 
specifications (Type B. MlL-STD-490). The Physical Configuration Audit (PCA) may 
be accomplished in the FSD phase, but is usually done in the beginning of the 
Production and Deployment phase on the first deliverable Cl that is built on hard 
tooling. A Production Readiness Review (PRR) is held at the end of the FSD phase to 
verify that the system is ready to proceed into the next phase. 

The output of FSD should result in a tested design that meets contract 
requirements and documentation necessarv' to enter the Production and Deployment 
phase, including Part II detail specifications (Type C, MIL-STD-490), a proposed RFP 
for the Production and Deployment phase, and an update of the plans proposed in the 
Validation phase. This data package receives a DCP update, SARC, and DSARC 
review. When all aspects of FSD have been accomplished, the DCP is forwarded to 
SECDEF for approval of production. 

4. Production and Deployment Phase 

The primary objective of the Production and Deployment phase is to 
produce and deliver an effective, supportable system at an optimum cost. In a 
production run where many items are to be delivered, manufacturing is usually 
accomplished in two segments. The first segment starts with low rate production of 
initial product batches or blocks and gradually increases to peak rate production as 
changes resulting from initial operational use, testing, production tooling, and 
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manufacturing are incorporated. Typically the first production configuration item from 
hard tooling is subjected to a PCA. Once it has been established that a production 
article is built in accordance with the Part II detail specifications, the PCA is complete 
and an approved production baseline is established for the configuration item audited. 
Once the PCAs for all the CIs are completed, a system level PCA is accomplished and 
the product baseline for the system is established. 
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